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Abstract 


This document describes the framework for an RFC Series and an RFC Editor function that 
incorporate the principles of organized community involvement and accountability that has 
become necessary as the Internet technical community has grown, thereby enabling the RFC 
Series to continue to fulfill its mandate. This document obsoletes RFC 4844. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Architecture Board (IAB) and represents information 
that the IAB has deemed valuable to provide for permanent record. It represents the consensus 
of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8729. 


Copyright Notice 


Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. 
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1. Introduction 


The first Request for Comments (RFC) document was published in April of 1969 as part of the 
effort to design and build what we now know of as the Internet. Since then, the RFC Series has 
been the archival series dedicated to documenting Internet technical specifications, including 
both general contributions from the Internet research and engineering community as well as 
standards documents. 


As described in the history of the first 30 years of RFCs ([RFC2555]), the RFC Series was created 
for the purpose of capturing the research and engineering thought that underlie the design of 
(what we now know of as) the Internet. As the Internet Engineering Task Force (IETF) was 
formalized to carry out the discussion and documentation of Internet standards, IETF documents 
have become a large part (but not the entirety) of the RFC Series. 


As the IETF has grown up and celebrated its own 30 years of history, its requirements for 
archival publication of its output have changed and become more rigorous. Perhaps most 
significantly, the IETF must be able to define (based on its own open consensus discussion 
processes and leadership directions) and implement adjustments to its publication processes. 


At the same time, the Internet engineering and research community as a whole has grown and 
come to require more openness and accountability in all organizations supporting it. More than 
ever, this community needs an RFC Series that is supported (operationally and in terms of its 
principles) such that there is a balance of: 


e expert implementation; 


e clear management and direction -- for operations and evolution across the whole RFC Series 
(whether originating in the IETF or not); and 


e appropriate community input into and review of activities. 


In the past, there has been confusion and therefore sometimes tension over where and how to 
address RFC issues that are particular to contributing groups (e.g., the IETF, the Internet 
Architecture Board (IAB), or independent individuals). It was not always clear where there 
should be community involvement versus RFC Editor control; depending on the issue, there 
might be more or less involvement from the IAB, the Internet Engineering Steering Group (IESG), 
or the community at large. There are similar issues with handling RFC Series-wide issues -- 
where to discuss and resolve them in a way that is balanced across the whole series. 


For example, there have been discussions about Intellectual Property Rights (IPR) for IETF- 
generated documents, but it's not clear when or how to abstract the portions of those discussions 
that are relevant to the rest of the RFC Series. Discussions of labeling (of RFCs in general, IETF 
documents in particular, or some combination thereof) generally must be applied to the whole 
RFC Series or not at all. Without an agreed-on framework for managing the RFC Series, it is 
difficult to have those discussions in a non-polarized fashion -- either the IETF dictating the 
reality of the rest of the RFC Series, or the RFC Series imposing undue restrictions on documents 
from the IETF. 
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As part of its charter (see Appendix A), the IAB has a responsibility for the RFC Editor. 
Acknowledging the IETF's needs and the general Internet engineering and research community's 
evolving needs, the IAB supports a future for the RFC Series that continues to meet its original 
mandate of providing the archival series for the technical research and engineering 
documentation that describes the Internet. 


With this document, the IAB provides the framework for the RFC Series and an RFC Editor 
function with the specific purpose of ensuring that the RFC Series is maintained and supported in 
ways that are consistent with the stated purpose of the RFC Series and the realities of today's 
Internet research and engineering community. The framework describes the existing "streams" 
of RFCs, draws a roadmap of existing process documents already defining the implementation, 
and provides clear direction of how to evolve this framework and its supporting pieces through 
discussion and future document revision. 


Specifically, this document provides a brief charter for the RFC Series, describes the role of the 
RFC Editor, the IAB, and the IETF Administrative Support Activity (IASA) in a framework for 
managing the RFC Series, and discusses the streams of input to the RFC Series from the various 
constituencies it serves. 


2. REC Series Mission 


The RFC Series is the archival series dedicated to documenting Internet technical specifications, 
including general contributions from the Internet research and engineering community as well 
as standards documents. 


RFCs are available free of charge to anyone via the Internet. 


3. Roles and Responsibilities 


As this document sets out the framework for supporting the RFC Series mission, this section 
reviews the updated roles and responsibilities of the entities that have had, and will have, 
involvement in continued support of the mission. 


3.1. RFC Editor 


Originally, there was a single person acting as editor of the RFC Series (the RFC Editor). The task 
has grown, and the work now requires the organized activity of several experts, so there are RFC 
Editors, or an RFC Editor organization. In time, there may be multiple organizations working 
together to undertake the work required by the RFC Series. For simplicity's sake, and without 
attempting to predict how the role might be subdivided among them, this document refers to this 
collection of experts and organizations as the "RFC Editor". 
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The RFC Editor is an expert technical editor and series editor, acting to support the mission of the 
RFC Series. As such, the RFC Editor is the implementer handling the editorial management of the 
RFC Series, in accordance with the defined processes. In addition, the RFC Editor is expected to 
be the expert and prime mover in discussions about policies for editing, publishing, and 
archiving RFCs. 


3.2. IAB 


In this model, the role of the IAB is to ensure that the RFC Series mission is being appropriately 
fulfilled for the whole community for which it was created. The IAB does not, organizationally, 
have comprehensive publishing or editorial expertise. Therefore, the role of the IAB is focused 
on ensuring that principles are met, the appropriate bodies and communities are duly informed 
and consulted, and the RFC Editor has what it needs in order to execute on the material that is in 
their mandate. 


It is the responsibility of the IAB to approve the appointment of the RFC Editor and to approve 
the general policy followed by the RFC Editor. 


3.3. Operational Oversight 


The IETF Administration Limited Liability Company (IETF LLC), as part of the IETF 
Administrative Support Activity (IASA), is responsible for administrative and financial matters 
for the IETF, the IAB, and the Internet Research Task Force (IRTF) [RFC8711]. The IASA is tasked 
with providing the funding for the RFC Editor. The IASA, through the IETF Executive Director, 
provides contractual and financial oversight of the RFC Editor. Additionally, as described in 
Section 3.1 of [RFC8728], the RFC Series Oversight Committee (RSOC), acting with authority 
delegated from the IAB, is responsible for ensuring that the RFC Series is run in a transparent 
and accountable manner, including design and execution of the RFC Series Editor selection 
process. 


The IETF Executive Director works with the IAB to identify suitable persons or entities to fulfill 
the mandate of the RFC Production Center and the RFC Publisher roles as defined in [RFC8728]. 


The IETF Executive Director establishes appropriate contractual agreements with the selected 
persons or entities to carry out the work that will satisfy the technical publication requirements 
defined for the various RFC input streams (see Section 5.2). The IETF Executive Director may 
define additional operational requirements and policies for management purposes to meet the 
requirements defined by the various communities. 


The IETF Administration LLC Board approves a budget for operation of the RFC Editor activity, 
and the IETF Executive Director establishes and manages the necessary operational agreements 
for the RFC Editor activity. 
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3.4. Policy Oversight 


The IAB monitors the effectiveness of the policies in force and their implementation to ensure 
that the RFC Editor activity meets the editorial management and document publication needs as 
referenced in this document. In the event of serious non-conformance, the IAB, either on its own 
initiative or at the request of the IETF Administration LLC Board, may require the IETF Executive 
Director to vary or terminate and renegotiate the arrangements for the RFC Editor activity. 


4. Framework 


With the RFC Series mission outlined above, this document describes a framework for 
supporting 


e the operational implementation of the RFC Series, 
based on 
e public process and definition documents, 
for which there are 
e clear responsibilities and mechanisms for update and change. 


Generally speaking, the RFC Editor is responsible for the operational implementation of the RFC 
Series. As outlined in Section 3.3, the IETF Executive Director provides the oversight of this 
operational role. 


The process and definition documents are detailed below, including responsibility for the 
individual process documents (maintenance and update). The RFC Editor works with the 
appropriate community to ensure that the process documents reflect current requirements. The 
IAB is charged with the role of verifying that appropriate community input has been sought and 
that any changes appropriately account for community requirements. 


There are three categories of activity, and a fourth category of series-wide rules and guidelines, 
described for implementing the RFC Series to support its mission: 


e Approval of documents. 

e Editing, processing, and publication of documents. 

e Archiving and indexing the documents and making them accessible. 
e Series rules and guidelines. 


4.1. Document Approval 


The RFC Series mission implicitly requires that documents be reviewed and approved for 
acceptance into the series. 
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4.1.1. Definition 


Section 5.1 describes the different streams of documents that are put to the RFC Editor for 
publication as RFCs today. While there may be general policies for approval of documents as 
RFCs (to ensure the coherence of the RFC Series), there are also policies defined for the approval 
of documents in each stream. Generally speaking, there is a different approving body for each 
stream. The current definitions are catalogued in Section 5.1. 


4.1.2. Operational Implementation 


Each stream has its own documented approval process. The RFC Editor is responsible for the 
approval of documents in one of the streams (Independent Submission stream, see Section 5.1.4) 
and works with the other approving bodies to ensure smooth passage of approved documents 
into the next phases, ultimately to publication and archiving as an RFC. 


4.1.3. Process Change 


From time to time, it may be necessary to change the approval processes for any given stream, or 
even add or remove streams. This may occur when the RFC Editor, the IAB, the body responsible 
for a given stream of documents, or the community determines that there are issues to be 
resolved in general for RFC approval or for per-stream approval processes. 


In this framework, the general approach is that the IAB will work with the RFC Editor and other 
parties to get community input, and it will verify that any changes appropriately account for 
community requirements. 


4.1.4. Existing Approval Process Documents 


The existing documents describing the approval processes for each stream are detailed in Section 
5.1. 


4.2. Editing, Processing, and Publication of Documents 


Producing and maintaining a coherent, well-edited document series requires specialized skills 
and subject matter expertise. This is the domain of the RFC Editor. Nevertheless, the community 
served by the RFC Series and the communities served by the individual streams of RFCs have 
requirements that help define the nature of the series. 


4.2.1. Definition 


General and stream-specific requirements for the RFC Series are documented in community- 
approved documents (catalogued in Section 5.2 below). 


Any specific interfaces, numbers, or concrete values required to make the requirements 
operational are the subject of agreements between the IASA and the RFC Editor (e.g., contracts, 
statements of work, service level agreements, etc). 
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4.2.2. Operational Implementation 


The RFC Editor is responsible for ensuring that editing, processing, and publication of RFCs are 
carried out in a way that is consistent with the requirements laid out in the appropriate 
documents. The RFC Editor works with the IASA to provide regular reporting and feedback on 
these operations. 


4.2.3. Process Change 


From time to time, it may be necessary to change the requirements for any given stream, or the 
RFC Series in general. This may occur when the RFC Editor, the IAB, the approval body for a 
given stream of documents, or the community determines that there are issues to be resolved in 
general for RFCs or for per-stream requirements. 


In this model, the general approach is that the IAB will work with the RFC Editor to get 
community input, and it will approve changes by validating appropriate consideration of 
community requirements. 


4.2.4. Existing Process Documents 


Documents describing existing requirements for the streams are detailed in Section 5.2. 


4.3. Archiving, Indexing, and Accessibility 


The activities of archiving, indexing, and making accessible the RFC Series can be informed by 
specific subject matter expertise in general document series editing. It is also important that they 
are informed by requirements from the whole community. As long as the RFC Series is to remain 
coherent, there should be uniform archiving and indexing of RFCs across all streams and a 
common method of accessing the resulting documents. 


4.3.1. Definition 


In principle, there should be a community consensus document describing the archiving, 
indexing, and accessibility requirements for the RFC Series. In practice, we continue with the 
archive as built by the capable RFC Editors since the series’ inception. 


Any specific concrete requirements for the archive, index, and accessibility operations are the 
subject of agreements between the IASA and the RFC Editor (e.g., contracts, statements of work, 
service level agreements, etc). 


4.3.2. Operational Implementation 


The RFC Editor is responsible for ensuring that the RFC archive and index are maintained 
appropriately and that the resulting documents are made available to anybody wishing to access 
them via the Internet. The RFC Editor works with the IASA for regular reporting and feedback. 
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4.3.3. Process Change 


Should there be a community move to propose changes to the requirements for the RFC archive 
and index or accessibility, the IAB will work with the RFC Editor to get community input, and it 
will approve changes by validating appropriate consideration of community requirements. 


4.3.4. Existing Process Documents 


There are no applicable process documents. 


4.4. Series-Wide Guidelines and Rules 


The RFC Series style and content can be shaped by subject matter expertise in document series 
editing. They are also informed by requirements by the using community. As long as the RFC 
Series is to remain coherent, there should be uniform style and content for RFCs across all 
streams. This includes, but is not limited to, acceptable language, use of references, and copyright 
rules. 


4.4.1. Definition 


In principle, there should be a community consensus document (or set of documents) describing 
the content requirements for the RFC Series. In practice, some do exist, though some need 
reviewing and more may be needed over time. 


4.4.2. Operational Implementation 


The RFC Editor is responsible for ensuring that the RFC Series guidelines are upheld within the 
RFC Series. 


4.4.3. Process Change 


When additions or changes are needed to series-wide definitions, the IAB will work with the RFC 
Editor and stream stakeholders to get community input and review. The IAB will approve 
changes by validating appropriate consideration of community requirements. 


4.4.4, Existing Process Documents 

Existing series-wide rules and guidelines documents include: 
e RFC Style Guide [RFC7322], 
e The Use of Non-ASCII Characters in RFCs [RFC7997], 


e Copyright and intellectual property rules [RFC5378], 
e Normative references [RFC3967] [RFC4897], [RFC8067]. 


5. RFC Streams 


Various contributors provide input to the RFC Series. These contributors come from several 
different communities, each with its own defined process for approving documents that will be 
published by the RFC Editor. This is nothing new; however, over time the various communities 


Housley & Daigle Informational Page 10 


RFC 8729 The RFC Series and RFC Editor February 2020 


and document requirements have grown and separated. In order to promote harmony in 
discussing the collective set of requirements, it is useful to recognize each in their own space -- 
and they are referred to here as "streams". 


Note that by identifying separate streams, there is no intention of dividing them or undermining 
their management as one series. Rather, the opposite is true -- by clarifying the constituent parts, 
it is easier to make them work together without the friction that sometimes arises when 
discussing various requirements. 


The subsections below identify the streams that exist today. There is no immediate expectation of 
new streams being created, and it is preferable that new streams NOT be created. Creation of 
streams and all policies surrounding general changes to the RFC Series are discussed above in 
Section 4. 


5.1. RFC Approval Processes 


Processes for approval of documents (or requirements) for each stream are defined by the 
community that defines the stream. The IAB is charged with the role of verifying that 
appropriate community input has been sought and that the changes are consistent with the RFC 
Series mission and this overall framework. 


The RFC Editor is expected to publish all documents passed to it after appropriate review and 
approval in one of the identified streams. 
5.1.1. IETF Document Stream 


The IETF document stream includes IETF WG documents as well as "individual submissions" 
sponsored by an IESG area director. Any document being published as part of the IETF standards 
process must follow this stream -- no other stream can approve Standards-Track RFCs or Best 
Current Practice (BCP) RFCs. 


Approval of documents in the IETF stream is defined by 


e the IETF standards process [RFC2026] (and its successors). 
e the IESG process for sponsoring individual submissions [SPONSOR]. 


Changes to the approval process for this stream are made by updating the IETF standards 
process documents. 


5.1.2. IAB Document Stream 


The IAB defines the processes by which it approves documents in its stream. Consistent with the 
above, any documents that the IAB wishes to publish as part of the IETF Standards Track 
(Standards or BCPs) are subject to the approval processes referred to in Section 5.1.1. 


The review and approval process for documents in the IAB stream is described in 


e the IAB process for review and approval of its documents [RFC4845]. 
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5.1.3. IRTF Document Stream 

The IRTF is chartered as an activity of the IAB. With the approval of the IAB, the IRTF may 
publish and update a process for publication of its own, non-IETF Standards-Track, documents. 
The review and approval process for documents in the IRTF stream is described in 


e IRTF Research Group RFCs [RFC5743]. 


5.1.4. Independent Submission Stream 


The RFC Series has always served a broader Internet technical community than the IETF. The 
"Independent Submission" stream is defined to provide review and (possible) approval of 
documents that are outside the scope of the streams identified above. 


Generally speaking, approval of documents in this stream falls under the purview of the RFC 
Editor, and the RFC Editor seeks input to its review from the IESG. 


The process for reviewing and approving documents in the Independent Submission stream is 
defined by 


e Procedures for Rights Handling in the RFC Independent Submission Stream [RFC5744], 
e Independent Submission Editor Model [RFC8730], 

e Independent Submissions to the RFC Editor [RFC4846], 

e The IESG and RFC Editor Documents: Procedures [RFC5742]. 


5.2. RFC Technical Publication Requirements 


The Internet engineering and research community has not only grown, it has become more 
diverse, and sometimes more demanding. The IETF, as a standards-developing organization, has 
publication requirements that extend beyond those of an academic journal. The IAB does not 
have the same interdependence with IANA assignments as the IETF stream does. Therefore, 
there is the need to both codify the publishing requirements of each stream, and endeavor to 
harmonize them to the extent that is reasonable. 


Therefore, it is expected that the community of effort behind each document stream will outline 
their technical publication requirements. 


As part of the RFC Editor oversight, the IAB must agree that the requirements are consistent with 
and implementable as part of the RFC Editor activity. 


5.2.1. IETF Documents 


The requirements for this stream are defined in [RFC4714]. 
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5.2.2. IAB Documents 


Although they were developed for the IETF standards process, the IAB has identified applicable 
requirements in [RFC4714] for its stream. In addition, procedures related to IPR for the IAB 
stream are captured in [RFC5745]. 


If the IAB elects to define other requirements, they should deviate minimally from those (in an 
effort to keep the collective technical publication requirements reasonably managed by one 
technical publisher). 


5.2.3. IRTF Documents 
The IRTF has identified applicable requirements in [RFC5743] for its stream. 


If the IRTF elects to define other requirements, they should deviate minimally from those (in an 
effort to keep the collective technical publication requirements reasonably managed by one 
technical publisher). 


5.2.4. Independent Submissions 


Procedures and processes for the Independent Stream are described in [RFC4846] and [RFC8730]. 


Although they were developed for the IETF standards process, the RFC Editor has identified 
applicable requirements in [RFC4714] for the Independent Submissions stream. In addition, 
procedures related to IPR for the independent submissions stream are captured in [RFC5744]. 


If the RFC Editor elects to define other requirements, they should deviate minimally from those 
(in an effort to keep the collective technical publication requirements reasonably managed by 
one technical publisher). 


6. Security Considerations 


The processes for the publication of documents must prevent the introduction of unapproved 
changes. Since the RFC Editor maintains the index of publications, sufficient security must be in 
place to prevent these published documents from being changed by external parties. The archive 
of RFC documents, any source documents needed to recreate the RFC documents, and any 
associated original documents (such as lists of errata, tools, and, for some early items, non- 
machine readable originals) need to be secured against failure of the storage medium and other 
similar disasters. 


7. Changes Since RFC 4844 


Sections 3.3, 3.4, and 4 have been updated to align with the restructuring of the IETF 
Administrative Support Activity (IASA). Under the new structure, the IETF LLC performs the 
tasks related to IASA that were previously assigned to the IETF Administrative Director and to 
the Internet Society. 


Many references were updated to point to the most recent documents. 
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Minor editorial changes were made to reflect 10 years of using the framework provided in RFC 
4884. For example, RFC 4844 said, "... this document sets out a revised framework ...", and it is 
now more appropriate to say, "... this document sets out the framework ...". 
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Appendix A. A Retrospective of IAB Charters and RFC Editor 


With this document, the IAB's role with respect to the RFC Series and the RFC Editor is being 
adjusted to work more directly with the RFC Editor and provide oversight to ensure the RFC 
Series mission principles and communities’ input are addressed appropriately. 


This section provides an overview of the role of the IAB with respect to the RFC Editor as it has 
been presented in IAB Charter RFCs dating back to 1992. The point of this section is that the IAB's 
role has historically been substantive -- whether it is supposed to be directly responsible for the 
RFC Series’ editorial management (circa 1992, Appendix A.1), or appointment of the RFC Editor 
organization and approval of general policy (circa 2000, Appendix A.3). 
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A.1. 1992 


[RFC1358] says: 


[The IAB's] responsibilities shall include: 
Pegal 
(2) The editorial management and publication of the Request 
for Comments (RFC) document series, which constitutes the 
archival publication series for Internet Standards and 
related contributions by the Internet research and 
engineering community. 


A.2. 1994 


[RFC1601] says: 


[The IAB's] responsibilities under this charter include: 
(d) RFC Series and IANA 
The IAB is responsible for editorial management and publication 


of the Request for Comments (RFC) document series, and for 
administration of the various Internet assigned numbers. 


Which it elaborates as: 


2.4 RFC Series and Assigned Numbers 
The RFC Series constitutes the archival publication channel 
for Internet Standards and for other contributions by the 
Internet research and engineering community. The IAB 


shall select an RFC Editor, who shall be responsible for 
the editorial management and publication of the RFC Series. 


A.3. 2000 


The most recent IAB Charter [RFC2850] says: 
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(d) RFC Series and IANA 


The RFC Editor executes editorial management and publication of 
the IETF "Request for Comment" (RFC) document series, which is 
the permanent document repository of the IETF. The RFC Series 
constitutes the archival publication channel for Internet 
Standards and for other contributions by the Internet research 
and engineering community. RFCs are available free of charge to 
anyone via the Internet. The IAB must approve the appointment 
of an organization to act as RFC Editor and the general policy 
followed by the RFC Editor. 
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